Skip to content

Conversation

@sbc100
Copy link
Collaborator

@sbc100 sbc100 commented Jan 12, 2026

Without this, its up to each callsite to inject callUserCallback (e.g. via safeSetTimeout vs setTimeout).

Forgetting to do so can resulting in strange behaviour such as exit() not work as expected when called from the continuation.

@sbc100 sbc100 force-pushed the asyncify_callUserCallback branch 2 times, most recently from b559688 to 6122ec5 Compare January 13, 2026 01:10
@sbc100 sbc100 requested a review from brendandahl January 13, 2026 01:10
@sbc100 sbc100 force-pushed the asyncify_callUserCallback branch from 6122ec5 to ee1f567 Compare January 13, 2026 01:12
@sbc100 sbc100 requested a review from kripken January 13, 2026 01:12
@sbc100
Copy link
Collaborator Author

sbc100 commented Jan 13, 2026

This change is going to be useful / essential for the followup to #26019 where i hope to make all (most) asyncify usage in the JS library automatic/transparent.

@sbc100 sbc100 force-pushed the asyncify_callUserCallback branch from ee1f567 to 20d5e0b Compare January 13, 2026 17:41
]
self.cflags += args
self.do_core_test('embind_lib_with_asyncify.cpp')
self.do_core_test('embind_lib_with_asyncify.cpp', assert_returncode=NON_ZERO)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does this change?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason is that because the asyncify continuation are now run in callUserCallback the handleException: got unexpected exception, calling quit_` which sets the node exit code to non-zero.

This test explicit has delayed_throw in it which throws and exception in an asyncify continuation.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But that delayed throw is handled early in the test,

    let delayedThrowResult = Module["delayed_throw"]();
    assert(delayedThrowResult instanceof Promise);
    let err = await delayedThrowResult.then(() => '', err => err.message);
    assert(err === 'my message', `"${err}" doesn't contain the expected error`);

The rest of the test runs after those lines, and it exits without error?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The .then(() => '', err => err.message); part handles the error, but the exit code is remembered because handleExcetpion calls quit_ which under node sets the overall process exit code:

process.exitCode = status;

So its kind of like the node implementation is remember the exit code even though the exception was handled further up. I don't know if this is ideal, but I imagine changing it would be very hard at this point.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. Yeah, probably not worth changing.

How about adding a comment in the python file, explaining why we expect the test to fail? Otherwise it is quite surprising I think.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed

@sbc100 sbc100 force-pushed the asyncify_callUserCallback branch from 20d5e0b to 257a6ad Compare January 13, 2026 23:43
@sbc100 sbc100 force-pushed the asyncify_callUserCallback branch from 257a6ad to d354cfd Compare January 13, 2026 23:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants